Skip to content

census: expose client interceptors #12050

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

AgraVator
Copy link
Contributor

No description provided.

@AgraVator AgraVator marked this pull request as ready for review May 13, 2025 04:18
Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm approving, but do consider the other API I mention in a comment, and whether we want to do that instead.

/**
* Returns a {@link ClientInterceptor} with default tracing implementation.
*/
public static ClientInterceptor newClientTracingInterceptor() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing all the statics is making me see why to more closely mirror GrpcOpenTelemetry. This could be fine as-is, because we don't care about it too much, but there do seem to be advantages in the GrpcOpenTelemetry API in clarity and letting us add options when needed.

If we had only configureServerBuilder() and configureChannelBuilder() on GrpcCensus and a builder to enable/disable stats/tracing, then gRPC could continue choosing the interceptor/tracer order and it would make configuring both OpenTelementry and OpenCensus more obvious.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants